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SYSTEM AND METHOD FOR 
IMPLEMENTING SELF-DEVICE CONTROL 
MODULES IN AN ELECTRONIC NETWORK 

CROSS-REFERENCE TO RELATED s 
APPLICATIONS 

This application relates to co-pending U.S. patent appli- 
cation Ser. No. 09/257,344, entitled "System And Method 
For Implementing Active Registries In An Electronic 
Network," filed on Feb. 25, 1999, which is hereby incorpo- 
rated by reference. The foregoing cross-referenced applica- 
tions are commonly assigned. 

BACKGROUND OF THE INVENTION 

15 

1. Field of the Invention 

This invention relates generally to electronic networks, 
and relates more particularly to a system and method for 
implementing self-device control modules in an electronic 
network. 20 

2. Description of the Background Art 

Implementing an effective method for managing commu- 
nications between electronic devices within an electronic 
network is a significant consideration for manufacturers and ^ 
designers of contemporary electronic systems. An electronic 
device in a distributed electronic network may advanta- 
geously communicate with other remote electronic devices 

in the network to share and substantially increase the 
resources available to individual devices in the network. For 3Q 
example, an electronic network may be implemented in a 
user's home to enable flexible and beneficial sharing of 
resources between various consumer electronic devices, 
such as personal computers, digital video disk devices, 
digital set-top boxes for digital broadcasting, television sets, 35 
and audio playback systems. 

Managing communications in a network of electronic 
devices may create substantial challenges for designers of 
electronic networks. For example, enhanced demands for 
increased functionality and performance may require more 40 
system processing power and require additional hardware 
resources across the network. An increase in processing or 
hardware requirements may also result in a corresponding 
detrimental economic impact due to increased production 
costs and operational inefficiencies. 45 

Network size is also a factor that affects the management 
of communications in an electronic network. Communica- 
tions in an electronic network typically become more com- 
plex as the number of individual devices or nodes increases. 
Assume that a particular device on an electronic network is 50 
defined as a local device with local software elements, and 
other devices on the electronic network are defined as 
remote devices with remote software elements. Accordingly, 
a local software module on the local device may need to 
communicate with various remote software elements on 55 
remote devices across the electronic network. However, 
successfully managing a substantial number of electronic 
devices across a single network may provide significant 
benefits to a system user. 

In certain instances, network communications between 60 
different types of devices may be accomplished using mul- 
tiple communication protocols or specifications. For 
example, a recently-manufactured device may employ an 
new communication protocol that was unavailable when 
other older network devices were designed. In addition, 65 
individual manufacturers may utilize different communica- 
tion protocols, depending on various design and marketing 
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considerations. In cases where multiple communication pro- 
tocols are utilized within a single electronic network, the 
network devices may benefit from efficient network mes- 
saging techniques. 

Therefore, for all the foregoing reasons, implementing an 
efficient method for managing communications between 
electronic devices in a distributed electronic network 
remains a significant consideration for designers, 
manufacturers, and users of electronic systems. 

SUMMARY OF THE INVENTION 

In accordance with the present invention, a system and 
method are disclosed for implementing self -device control 
modules in an electronic network. In one embodiment of the 
invention, initially, an event occurs in a type B device on the 
electronic network. The type B device may preferably be 
implemented as a base device or a legacy device that utilizes 
a type B communications protocol. The foregoing event may 
include an occurrence of any relevant type or description in 
the type B device or on the electronic network. 

In response to the foregoing event, the type B device may 
preferably transmit a type B communication to a type A 
device on the electronic network. The type A device is 
preferably implemented as a full device or an intermediate 
device that includes a set of local network software which is 
compatible with a type A communications protocol. The 
foregoing type B communication may preferably relate in 
some manner to the event that previously occurred on the 
electronic network. 

In accordance with the present invention, a self-device 
control module (self-DCM) in the network software of the 
type A device preferably accesses the received type B 
communication, and then advantageously translates the type 
B communication into a type A communication that may be 
understood by network software of the type A device. 

In one embodiment, a driver interface in the self-DCM 
preferably functions as an effective interface to a device 
driver of the type A device for receiving and handling 
information (such as the type B communication) sent to the 
device driver from other devices on the electronic network. 
A command processor then preferably may access the infor- 
mation received by driver interface, and rcsponsively utilize 
a handler mechanism that determines how to successfully 
process or interpret the received information. 

Next, a translator may preferably convert the received 
information into translated information that is configured in 
a network software format (type A) which is compatible 
with the protocol and specifications of various sets of 
network software on devices across the electronic network. 
Finally, a network software interface may provide the trans- 
lated information that has been converted into the network 
software format to network software on the type A device. 

The self-DCM may preferably also post the translated 
type A communication to an event manager in network 
software of the type A device. The self-DCM preferably 
posts the translated type A communications as a network 
event. The event manager may preferably then notify any 
interested devices or software modules that have subscribed 
for notification regarding the particular network event rep- 
resented by the type B communication. In accordance with 
the present invention, remote sets of network software 
residing on respective remote devices preferably may sub- 
scribe for notification whenever the self-DCM receives a 
type B communication. 

Finally, the subscribers may react to the notification from 
the event manager in any appropriate manner, depending 
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upon the type of event and the type of subscribing device or mented using a larger or smaller number of devices than the 

software module. The invention is discussed here in the four devices (device A 112(a) through device D 112(a)) 

context of a single self-DCM. However, the present inven- shown in the FIG. 1 embodiment. 

tion is also contemplated for use with multiple self-DCMs \ n the FIG. 1 network 110, device A 112(a), device B 

residing on respective network devices across the electronic 5 112(6), device C 112(c), and device D 112(a) preferably 

network. The present invention thus provides a system and communicate with each other through a commonly-shared 

method to efficiently implement self-device control modules network bus 120. In the FIG. 1 embodiment, network bus 

across an electronic network. 120 is preferably implemented according to a P1394 Stan- 

DDTCC nncmiDTrnM -run no a^/tm^c dard for a Hi 8 h Performance Serial Bus, IEEE, 1995, which 

BRIEF DESCRIPTION OF THE DRAWINGS 10 fc Qereby by reference „ However, in alternate 

FIG. 1 is a block diagram for one embodiment of an embodiments, other appropriate and compatible intercon- 

electronic network, in accordance with the present inven- nectivity standards are also contemplated for use in con- 

tion; junction with the present invention. 

FIG. 2 is a block diagram for one embodiment of an In the FIG. 1 embodiment, network 110 may preferably be 

exemplary device from FIG. 1, in accordance with the 35 configured to operate in accordance with the Home Audio/ 

present invention; Video Interoperability (HAVi) core specification (version 

FIG. 3 is a diagram for one embodiment of the memory 10 belt, at www.HAVi.org) which is hereby incorporated by 

of FIG. 2, in accordance with the present invention; reference. Therefore, device A 112(a), device B 112(6), 

FIG. 4 is a diagram for one embodiment of the network 20 devicc C ^> a f nd devicc D 112(a) may be implemented 

software of FIG. 3, in accordance with the present invention; * s f consume 1 r elect romcs devices, including 

i^™, °ut not hunted to, personal computers, digital video disk 

FIG. 5 is a diagram for one embodiment of the self-DCM deviceS) television sets, audio reproduction systems, video 

of FIG. 4, in accordance with the present invention; tapc recorders (VC Rs), and set-top boxes for digital video 

FIG. 6 is a diagram illustrating one embodiment for the broadcasting. However, in various alternate embodiments, 

utilization of network devices with multiple communication 25 network 110 may readily be implemented as any appropriate 

protocols; electronic network configured to permit communication 

FIG. 7 is a block diagram illustrating the utilization of a between any desired types of electronic devices. 

self-DCM, in accordance with one embodiment of the In the FIG. 1 embodiment, the various electronic devices 

present invention; and 3Q that form part of network 110 preferably include the fol- 

FIG. 8 is a flowchart of method steps for utilizing a lowing four categories of electronic devices: full devices 

self-DCM, in accordance with one embodiment of the (FD), intermediate devices (ID), base devices (BD), and 

present invention. legacy devices (LD). The foregoing four categories of 

electronic devices (FD, ID, BD, and LD) are further dis- 

DETAILED DESCRIPTION OF THE cussed below m conjunction with FIGS. 2 and 3. In alternate 

PREFERRED EMBODIMENT embodiments of the present invention, network 110 may 

The present invention relates to an improvement in elec- readily include various other categories of electronic devices 

tronic network technology. The following description is in addition to, or instead of, the four categories of FD, ID, 

presented to enable one of ordinary skill in the art to make BD, and LD. 

and use the invention and is provided in the context of a 40 Referring now to FIG. 2, a block diagram for one embodi- 

patent application and its requirements. Various modifica- ment of an exemplary device 112 from FIG. 1 is shown, in 

tions to the preferred embodiment will be readily apparent to accordance with the present invention. In the FIG. 2 

those skilled in the art and the generic principles herein may embodiment, device 112 preferably includes, but is not 

be applied to other embodiments. Thus, the present inven- limited to, a processor 212, an input/output interface (I/O) 

tion is not intended to be limited to the embodiment shown, 45 214, and a memory 216 that are each coupled to, and 

but is to be accorded the widest scope consistent with the communicate with each other via, a common device bus 

principles and features described herein. 218. In the FIG. 2 embodiment, device 112 is preferably 

The present invention comprises a system and method for configured to represent either a Ml device or an intermedi- 

implementing self -device control modules in an electronic ate device, as referred to above in the discussion of the FIG. 

network, and preferably includes a first device that transmits 50 1 network 110. 

an event communication to a second device across the In the FIG. 2 embodiment, processor 212 may be imple- 

electronic network in accordance with a first communica- mented to include any appropriate and compatible generic, 

tions protocol. Aself-device control module in a local set of multi-purpose microprocessor device. The FIG. 2 input/ 

network software on the second device responsively output interface (I/O) 214 preferably provides an effective 

accesses and converts the received event communication 55 interface to facilitate communications between device 112 

into a translated communication that complies with a second and network bus 120 (FIG. 1). In the FIG. 2 embodiment, 

communications protocol which is compatible with the local memory 216 may be implemented to include any combina- 

set of network software on the second device. In accordance tion of desired storage devices, including, but not limited to, 

with the present invention, the self -device control module read-only memory (ROM), random-access memory (RAM), 

also may provide the translated communication to sets of 60 and various types of non-volatile memory, such as floppy 

remote network software across the electronic network. disks or hard disks. The contents and functionality of 

Referring now to FIG. 1, a block diagram for one embodi- memory 216 are further discussed below in conjunction with 

ment of an electronic network 110 is shown, in accordance FIGS. 3 and 4. 

with the present invention. In the FIG. 1 embodiment, Referring now to FIG. 3, a diagram for one embodiment 

network 110 includes, but is not limited to, device A 112(a), 65 of FIG. 2 memory 216 is shown, in accordance with the 

device B 112(6), device C 112(c), and device D 112(d). In present invention. In the FIG. 3 embodiment, memory 216 

other embodiments, network 110 may readily be imple- includes one or more device applications 312, a network 
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application program interface (API) 314, network software 
316, self-describing data (SDD) 320, a device driver 318, a 
platform-specific application program interface (API) 322, 
and a vendor-specific platform 324. In alternate 
embodiments, memory 216 may readily include various 5 
components and elements that are different from, or in 
addition to, those software components 312 through 324 
discussed in conjunction with the FIG. 3 embodiment. 

In the FIG. 3 embodiment, device application^) 312 
preferably include software instructions that are executed by 10 
processor 212 (FIG. 2) to effectively manage and control the 
functionality of device 112. Network API 314 preferably 
serves as an interface between various elements of network 
software 316 and device application 312. 

In the FIG. 3 embodiment, network software 316 prefer- 15 
ably includes one or more software elements that are 
executed by processor 212 to advantageously permit device 
112 to communicate and cooperate with other devices in 
network 110. The contents and functionality of network 
software 316 are further discussed below in conjunction 20 
with FIG. 4. 

Self-describing data (SDD) 320 preferably includes vari- 
ous types of relevant information regarding device 112. For 
example, SDD 320 may include information specifying the 
manufacturer, model, version, serial number, and other fixed 25 
data that specifically corresponds to device 112. Device 
driver 318 preferably includes appropriate software instruc- 
tions that permit device 112 to communicate with network 
bus 120 (FIG. 1). 

In the FIG. 3 embodiment, platform-specific API 322 
provides an interface that preferably permits network soft- 
ware 316 to communicate with vendor-specific platform 
324. In the FIG. 3 embodiment, vendor-specific platform 
324 may include basic operating system software for sup- 
porting low-level operations of device 112. 

The FIG. 3 embodiment of memory 216 typically corre- 
sponds to a full device (or FD, as discussed above in 
conjunction with FIG. 1) that preferably includes a complete 
set of network software 316 to permit optimal compatibility 
and functionality with network 110. Alternately, memory 
216 may correspond to an intermediate device (ID) which 
includes only a reduced set of software elements from 
network software 316. In contrast, a device-control module 
for a base device (BD) is preferably hosted on network 110 
by a full device or an intermediate device, and therefore the 
base device typically does not include network software 
316. A base device, however, preferably does include self- 
describing data 320 and a device driver 318. 

A legacy device (LD) may be defined as a device that does 
not comply with the architectural specifications of network 
110 and network software 316. Legacy devices typically 
were designed and manufactured prior to the design and 
implementation of network 110 and network software 316. 
Therefore, a legacy device is preferably hosted on network 
110 by a full device or an intermediate device, and typically 
does not include network software 316 or self -describing 
data 320. A base device or a legacy device, however, may 
include a device driver 318 for interfacing with network bus 
120. Full devices, intermediate devices, base devices, and 60 
legacy devices are further discussed in the Home Audio/ 
Video Interoperability (HAVi) core specification (see pages 
3 through 22) that has been previously incorporated by 
reference. 

Referring now to FIG. 4, a diagram for one embodiment 65 
of the network software 316 of FIG. 3 is shown, in accor- 
dance with the present invention. In the FIG. 4 embodiment, 
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network software 316 preferably comprises a number of 
software elements, including a registry 412, an event man- 
ager 414, a device control module (DCM) manager 416, a 
stream manager 418, a resource manager 420, one or more 
device control modules (DCMs) 422 and one or more 
corresponding functional control modules (FCMs) 423, a 
messaging system 424, a communication media manager 
(CMM) 426, and a self-device control module (self-DCM) 
425. 

In the FIG. 4 embodiment, software elements 412 through 
426 are preferably configured to function in accordance with 
the Home Audio/Video Interoperability (HAVi) architecture 
which has previously been incorporated herein by reference. 
However, in alternate embodiments, network software 316 
may readily conform to any other appropriate and compat- 
ible interoperability architecture, and may also include vari- 
ous software elements that are different from, or in addition 
to, those elements 412 through 426 that are presented in the 
FIG. 4 embodiment. 

In the FIG. 4 embodiment, registry 412 may preferably 
include a listing of software elements in network software 
316. Registry 412 also preferably may include relevant 
element information or attributes corresponding to the listed 
software elements. For example, elements 412 through 426 
from network software 316 and corresponding element 
information may be listed in registry 412. Registry 412 
therefore may serve as a directory service for applications 
312 or software elements in network 110. Registry 412 may 
thus allow any application or software element to obtain a 
software element identifier (SEID) for identifying and locat- 
ing another software element in network 110. In accordance 
with the present invention, registry 412 may also include a 
remote registry list that identifies all remote registries on 
network 110. 

In the FIG. 4 embodiment, event manager 414 preferably 
serves as a network-event notification service to notify 
various software elements (that have previously subscribed 
for notification) about the occurrence of a specified network 
event, such as a change in a software element or a change in 
network 110. DCM manager 416 is preferably responsible 
for installing and removing DCMs 422 on full devices or 
intermediate devices. Stream manager 418 is preferably 
responsible for managing real-time transfer of data and other 
information between various functional components of net- 
work 110. 

In the FIG. 4 embodiment, resource manager 420 prefer- 
ably facilitates the sharing of various resources and sched- 
uling of various actions in network 110. A device control 
module (DCM) 422 preferably includes a software element 
that is used to control a specific associated device on 
network 110. A given DCM 422 preferably includes one or 
more directly-corresponding functional control modules 
(FCMs) 423 that each control a specific functional compo- 
nent within the particular device 112 that corresponds to the 
FCM 423. A fiill device or an intermediate device may 
preferably host a DCM 422 to control a remote base device 
or a remote legacy device on network 110. In the FIG. 4 
embodiment, messaging system 424 is preferably respon- 
sible for bi-directionally transferring various messages 
between the software elements of network software 316. 
Communication media manager (CMM) 426 coordinates 
and manages asynchronous and isochronous communica- 
tions through device driver 318 onto network bus 120. 

Network software 316 preferably performs a number of 
significant and related operations whenever a particular 
device is removed from, or added to, network 110. When a 
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device is added or removed from network 110, then network 112(6), and 112(c) is shown. The following discussion of the 

bus 120 preferably triggers a bus reset event which notifies FIG. 6 embodiment is presented for purposes of illustration 

all connected devices about the change in network 110. only, and devices 112(a), 112(6), and U2(c) may readily be 

Following the bus reset event, all DCM managers 416 in utilized various other ways in alternate embodiments of 

network 110 preferably perform a negotiation procedure to 5 network 110. 

determine which, if any, DCM manager 416 is the most i n the FIG. 6 embodiment, for purposes of illustration, 

appropriate host for controlling the newly-added device 112. device A (112(c)) and device C (112(c)) are preferably 

Each DCM manager 416 in network 110 may therefore implemented as either full devices (FD) or intermediate 

maintain a current list of all devices in network 110. Once devices (ID). In contrast, device B (112(b)) is preferably 

a given DCM manager 416 is selected as host, that host 10 implemented as a base device (BD) or a legacy device (LD) 

DCM manager 416 responsively instantiates a new DCM that communicates using a different messaging protocol or 

422 as an abstraction of the control interface of the newly- specification than that utilized by device A (112(a)) and 

added device. Network software 316 preferably also updates device C (112(c)). Furthermore, in the FIG. 6 embodiment, 

relevant software element information in registry 412 when- device A (112(a)) preferably hosts a device control module 

ever a device is removed from, or added to, network 110. is 422 for controlling and communicating with device B (112 

In accordance with the present invention, self-DCM 425 (6)). In one embodiment of FIG. 6, the various communi- 

preferably includes software instructions for advantageously cations 120(a-c) may designate logical communications 

receiving and handling information that is transmitted from between devices of network 110, and therefore may not 

other devices on network 110 using various types of com- necessarily imply a physical connection, 

munications protocols and specifications. The configuration 20 fo practic ^ device application 312 of device A (112(a)) 

and utilization of self-DCM 425 is further discussed below may g enerat e a type A communication to DCM 422 in 

in conjunction with FIGS. 5 through 8. network software 316(a) for controlling or communicating 

Referring now to FIG. 5, a diagram for one embodiment with device B 112(6)). In the FIG. 6 embodiment, a type A 

of the FIG. 4 self-DCM 425 is shown, in accordance with the communication is preferably transmitted according to a 

present invention. In the FIG. 5 embodiment, self-DCM 425 25 protocol and specification that are directly compatible with 

includes, but is not limited to, a driver interface 518, a network software 316. For example, in the FIG. 6 

command processor 516, a translator 514, and a network embodiment, a type A communication may conform to the 

software interface 512. In alternate embodiments, self-DCM HAVi specification that has previously been incorporated by 

425 may include various elements that are different from, or reference. However, device B (112(6)) preferably utilizes a 

in addition to, those discussed in conjunction with the FIG. 30 messaging protocol and specification that are different from 

5 embodiment. the foregoing type A communications, and therefore device 

In the FIG. 5 embodiment, self-DCM 425 is preferably B (112(6) may not directly understand type Acommunica- 

implemented in network software 316 of a particular local tions from device application 312. 

device 112 to represent and control various functions of that ^ Therefore, DCM 422 and device driver 318(a) preferably 
local device 112 on network 110. Self-DCM 425 preferably 3 convert the type A communication into a type B communi- 
comprises an abstraction of the control interface of the local cation that is transmitted to device driver 318(6) in device B 
device 112 that may then be utilized to interact between (112(6)) via network bus 120(a). In the FIG. 6 embodiment, 
various software modules and the local device 112. a type B communication is preferably transmitted according 
In the FIG. 5 embodiment, self-DCM 425 preferably may 4Q to a protocol and specification that are not directly compat- 
receive information or communications that are transmitted ible with network software 316. For example, in the FIG. 6 
from remote devices on network 110 using a variety of embodiment, a type B communication may conform to the 
messaging protocols or specifications that are different from P1394 specification that has been previously incorporated by 
the messaging protocol and specifications of network soft- reference. More specific examples of such PI 394 protocols 
ware 316, and are therefore not necessarily compatible with 45 and specifications are discussed in "AV/C Digital Interface 
or understood by network software 316. Command Set General Specification, Version 3.0, Apr. 15, 
In accordance with the present invention, driver interface 1998/' and in "International Standard IEC 61883-1, First 
518 preferably functions as an effective interface between Edition, 1998," which are hereby incorporated by reference, 
device driver 318 (FIG. 3) and self-DCM 518 to receive and After receiving the type B communication (from DCM 
handle information sent to device driver 318 from other 50 422 via device driver 318(a), network bus 120(a), and 
devices via network bus 120. Command processor 516 then device driver 318(6)), the device B (112(6)) may respon- 
preferably accesses the information received by driver inter- sively take appropriate action, depending upon the nature of 
face 518, and responsively utilizes a handler mechanism that the information initially sent from device application 312. 
determines how to successfully process or interpret the In accordance with the present invention, device B (112 
received information. ss (6)) may also transmit a type B communication from device 
In the FIG. 5 embodiment, translator 514 preferably may driver 318(6) through network bus 120(6) to device driver 
then convert the received information into translated in for- 318(c) of device C (112(c)). In the FIG. 6 embodiment, the 
mation that is configured in a network software format type B communication transmitted over network bus 120(6) 
which is compatible with the protocol and specifications of may relate to any desired topic, including an event, state, 
network software 316. Finally, network software interface 60 request, command, action, or other occurrence. For example, 
512 may then provide the translated information that has device B (112(6) may request information from device C 
been converted into the network software format to network (112(c)), or alternately, device B (112(6) may notify device 
software 316. Additional details regarding the functionality C (112(c)) about an occurrence on network 110, such as a 
and utilization of self-DCM 425 are further discussed below change of the state of device B (112(6)). 
in conjunction with FIGS. 6 through 8. 6 5 In the FIG. 6 embodiment, device B (112(6)) may trans- 
Referring now to FIG. 6, a diagram illustrating one mit type B communications to device driver 3 18(c) of device 
embodiment for the utilization of network devices 112(a), C (112(c)) using a Control and Status Registers (CSR) 
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Architecture for microcomputer buses that is discussed in 
detail in "International Standard ANSI/IEEE Std 1212, First 
Edition, 1994/' which is hereby incorporated by reference. 
In the FIG. 6 embodiment, the CSR architecture may 
preferable be implemented, for example, as part of device 
driver 318(c) to allow other devices in network 110 to locate 
and communicate with device C 112(c). In alternate 
embodiments, devices coupled to network bus 120 may 
communicate in accordance with various other mechanisms 
and standards. 

Once device driver 318(c) has received the type B com- 
munication from device B 112(6), then device C (112(c)) 
may potentially take action based on the nature of the type 
B communication. However, network software 316(c) 
remains unaware of the type B communication received via 
network bus 120(b) because network software 316(c) does 
not directly understand type B communications, and no 
mechanism exists to inform network software 316(c) about 
the received type B communication. Furthermore, device A 
(112(a)) also may have no knowledge about information that 
is encoded in the type B communications from device B 
(112(b)). The inability of network software 316 of network 
110 to learn about the occurrence and significance of type B 
communications may significantly impair the overall effi- 
ciency and effectiveness of network messaging and com- 
munications. 

Referring now to FIG. 7, a block diagram illustrating the 
utilization of a self-DCM 425 is shown, in accordance with 
one embodiment of the present invention. The following 
discussion of the FIG. 7 embodiment is presented for 
purposes of illustration only, and devices 112(a), 112(b), and 
112(c) may readily be utilized various other ways in alter- 
nate embodiments of network 110. 

In the FIG. 7 embodiment, for purposes of illustration, 
device A (112(a)) and device C (112(c)) are preferably 
implemented as either full devices (FD) or intermediate 
devices (ID). In contrast, device B (112(b)) is preferably 
implemented as a base device (BD) or a legacy device (LD) 
that communicates using a different messaging protocol or 
specification than that utilized by device A (112(a)) and 
device C (112(c)). In alternate embodiments, device B 
(112(b)) may also be implemented as a full device (FD) or 
an intermediate device (ID). Furthermore, in the FIG. 7 
embodiment, device A (112(a)) preferably hosts a device 
control module 422 for controlling and communicating with 
device B (112(b)). In one embodiment of FIG. 7, the various 
communications 120(a-<) may designate logical communi- 
cations between devices of network 110, and therefore may 
not necessarily imply a physical connection. 

In practice, device application 312 of device A (112(a)) 
may generate a type A communication to DCM 422 in 
network software 316(a) for controlling or. communicating 
with device B 112(b)). In alternate embodiments, DCM 422 
may be implemented as a FCM 423 (FIG. 4) or any other 
appropriate software module. In the FIG. 7 embodiment, a 
type A communication is preferably transmitted according to 
a protocol and specification that are directly compatible with 
network software 316. For example, in the FIG. 7 
embodiment, a type A communication may conform to the 
HAVi specification that has previously been incorporated by 
reference. However, device B (112(b)) preferably utilizes a 
messaging protocol and specification that are different from 
the foregoing type A communications, and therefore device 
B (112(b) may not directly understand type A communica- 
tions from device application 312. 

Therefore, DCM 422 and device driver 318(a) preferably 
convert the type A communication into a type B communi- 



cation that is transmitted to device driver 318(b) in device B 
(112(b)) via network bus 120(a). In the FIG. 7 embodiment, 
a type B communication is preferably transmitted according 
to a protocol and specification that are not directly compat- 

s ible with network software 316. For example, in the FIG. 7 
embodiment, a type B communication may conform to the 
P1394 specification that has been previously incorporated by 
reference. More specific examples of such PI 394 protocols 
and specifications are discussed in "AV/C Digital Interface 

10 Command Set General Specification, Version 3.0, Apr. 15, 
1998," and in "International Standard IEC 61883-1, First 
Edition, 1998," which have been previously incorporated by 
reference. 

After receiving the type B communication (from DCM 
15 422 via device driver 318(a), network bus 120(a), and 
device driver 318(b)), the device B (112(b)) may respon- 
sively take appropriate action, depending upon the nature of 
the information initially sent from device application 312. 

In accordance with the present invention, device B (112 
(b)) may also transmit a type B communication from device 
driver 318(b) through network bus 120(b) to device driver 
318(c) of device C (112(c)). In the FIG. 7 embodiment, the 
type B communication transmitted over network bus 120(b) 
may relate to any desired topic, including an event, state, 
request, command, action, or other occurrence. For example, 
device B (112(b) may request information from device C 
(112(c)), or alternately, device B (112(b) may notify device 
C (112(c)) about an occurrence on network 110. 

In the FIG. 7 embodiment, device B (112(b)) may trans- 
mit type B communications to device driver 318(c) of device 
C (112(c)) using a Control and Status Registers (CSR) 
Architecture for microcomputer buses that is discussed in 
detail in "International Standard ANSI/IEEE Std 1212, First 
Edition, 1994/' which has been previously incorporated by 
reference. In the FIG. 7 embodiment, the CSR architecture 
may preferable be implemented, for example, as part of 
device driver 318(c) to allow other devices in network 110 
to locate and communicate with device C 112(c). In alternate 
4Q embodiments, devices coupled to network bus 120 may 
communicate in accordance with various other mechanisms 
and standards. 

Once device driver 318(c) has received the type B com- 
munication from device B 112(b), then device C (112(c)) 

45 may potentially take action based on the nature of the type 
B communication. In addition, in accordance with the 
present invention, . a self-DCM 425 in network software 
(316(c) may advantageously utilize driver interface 518 
(FIG. 5) to communicate with device driver 318(c) to 

50 thereby gain access to the type B communications provided 
via network bus 120(b). In the FIG. 7 embodiment, driver 
interface 518 of self-DCM 425 preferably incorporates the 
CSR architecture of device driver 318(c) to facilitate com- 
munications with other devices on network 110. 

55 As discussed above, in conjunction with FIG. 5, once 
driver interface 518 has accessed the received type B 
communication, then command processor 516 may readily 
process the type B communication. Translator 514 may then 
access and translate the type B communication into a type A 

60 communication that is compatible with, and understood by, 
network software 316(c). Finally, network software inter- 
face 512 may provide the translated type A communication 
to network software 316(c) using any effective technique or 
methodology. Network software 316(c) may thus efficiently 

65 receive prompt notification concerning the receipt of the 
type B communication by device driver 318(c), and also 
determine the specific substance of the type B communica- 
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tion. In alternate embodiments, self-DCM 425 may readily In some embodiments of the present invention, self- D CM 

utilize any other appropriate means to provide the type B 425 may advantageously be utilized to avoid various other 

communication to network software 316(c) in a format that potential conflicts or problems in addition to the foregoing 

is understood by network software 316(c). conflict between a scheduled reservation and a conflicting 

In accordance with the present invention, self-DCM 425 s communication. For example, in response to a given type B 

may also disseminate the translated type A communication communication, self-DCM 425 may instigate an analysis of 

across network 110 to other remote devices that include various states or conditions in network 110 to thereby 

compatible remote sets of network software 316. In general, regulate the response to the type B communication by 

self-DCM 425 may use network software interface 512 to devices in network 110. 

directly provide the translated type A communication to 10 In the FIG. 7 embodiment, self-DCM 425 is implemented 
other type A devices. For example, in the FIG. 7 as part of network software 316(c) of device C (112(c)). 
embodiment, self-DCM 425 of device C (112(c)) may However, in various alternate embodiments, self-DCM 425 
provide the translated type A communication to network may readily be implemented in any suitable location(s) on 
software 316(a) of device A (112(a)) via network bus 120(c). any of one or more network devices across network 110. 
Alternately, network software 316(c) may determine that 15 Referring now to FIG. 8, a flowchart of method steps for 
broadcasting the translated type A communication is not utilizing a self-DCM 425 is shown, in accordance with one 
appropriate in certain instances, and may respond to device embodiment of the present invention. The following method 
B (112(6) using a type B communication. steps of the FIG. 8 embodiment illustrate an exemplary use 
In one embodiment of the present invention, self-DCM of self-DCM 425, However, in alternate embodiments, self- 
425 may post the translated type A communication to event 20 DCM 425 may readily function and be utilized in a variety 
manager 414 (FIG. 4) of network software 316(c) as a of other effective and advantageous ways, 
network event. Various interested software modules and In the FIG, 8 embodiment, initially, in step 812, a par- 
devices across network 110 may subscribe for notification ticular event occurs in a type B device 112(6) on network 
from event manager 414 whenever a particular network 110, In the FIG, 8 embodiment, the foregoing event may 
event occurs. Therefore, when self-DCM 425 posts the 25 preferably include an occurrence of any relevant type or 
translated type A communication to event manager 414 as a description. In step 814, in response to the step 812 event, 
network event, then an event manager 414 may promptly the type B device 112(b) preferably transmits a type B 
transmit the translated type A communication to all inter- communication to a type A device 112(c) on network 110. 
ested subscribers as a notification. In this manner, the The type B communication transmitted in step 814 prefer- 
information in the translated type A communication may 30 ably relates in some manner to the event that occurred in step 
become known to any set of network software 316 across 812. 

network 110. One mechanism for utilizing event manager i n slep gi^ a self-DCM 425 in network software 316(c) 

414 to propagate notifications of network events is further 0 f me type A device 112(c) preferably accesses the received 

discussed in co-pending U.S. patent application Ser. No. type B communication transmitted in step 814, and then 

09/257,344, entitled "System And Method For Implement- advantageously translates the type B communication into a 

ing Active Registries In An Electronic Network," filed on type A communication that is compatible with, and may be 

Feb. 25, 1999, which has previously been incorporated understood by, network software 316(c) of the type A device 

herein by reference. 112(c). 

Referring again to FIG. 6, in certain circumstances, a 4Q in step 818, the self-DCM 425 preferably posts the 

source network device may utilize a resource manager 420 translated type A communication of step 816 to an event 

(FIG. 4) to reserve a target network device for performing a manager 414 in network software 316(c) of the type A 

specific scheduled action. For example, in the FIG. 6 device U2(c). The self-DCM 425 preferably posts the 

embodiment, device A (112(a)) may use a type A commu- translated type A communications as a network event. Then, 

nication to reserve device C (112(c)) for automatically 45 in step 820, the event manager 414 preferably notifies any 

performing a scheduled action at a specified time. interested devices or software modules that have subscribed 

If device B (112(6) sends a conflicting type B communi- for notification regarding this particular network event. In 

cation to device C (112(c)) for requesting device C (112(c)) the FIG. 8 embodiment, various remote versions of network 

to perform a conflicting action, then, the conflicting type B software 316 residing on respective remote devices prefer- 

commu nication may dis advantageously override the 50 ably subscribe for notification whenever self-DCM 425 

previously-scheduled reservation made by device A (112(a). receives a type B communication. 

It should be noted that the FIG. 6 network software 316(c) Finally, in step 822, the subscribers may react to the 

lacks a self-DCM 425, and therefore network software 316 notification from event manager 414 in any appropriate 

on network 110 may be unaware of the conflicting type B manner, depending upon the type of event and the type of 

communication and the danger of overriding the previously- 5S subscribing device or software module. The FIG. 8 embodi- 

scheduled reservation made by device A (112(a). ment is discussed in the context of a single self-DCM 425. 

In contrast, in the FIG. 7 embodiment, network software However, the present invention is equally contemplated for 

316(c) includes a self-DCM 425 that may advantageously use with multiple self-DCMs residing on respective network 

inform network software 316 on network 110 that device B devices 112 across network 110. 

(112(b) has sent a conflicting type B communication to 60 The invention has been explained above with reference to 

device C (112(c)). In response, resource manager 420 may a preferred embodiment. Other embodiments will be appar- 

efficiently arbitrate and resolve the conflict between the ent to those skilled in the art in light of this disclosure. For 

previously-scheduled reservation from device A (112(a) and example, the present invention may readily be implemented 

the conflicting type B communication from device B (112 using configurations and techniques other than those 

(b). In accordance with the present invention, resource 65 described in the preferred embodiment above. Additionally, 

manager 420 may utilize any appropriate methodologies for the present invention may effectively be used in conjunction 

resolving the foregoing conflict. with systems other than the one described above as the 
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preferred embodiment. Therefore, these and other variations 
upon the preferred embodiments are intended to be covered 
by the present invention, which is limited only by the 
appended claims 
What is claimed is: 5 

1. A system for efficiently implementing an electronic 
network, comprising: 

a first device coupled to .said electronic network for 
transmitting an event communication according to a 
first communications protocol; and io 

a self-DCM coupled to said electronic network for con- 
verting said event communication into a translated 
communication that utilizes a second communications 
protocol which is compatible with a second device on 
said electronic network. 35 

2. The system of claim 1 wherein said event communi- 
cation and said first communications protocol are imple- 
mented according to an IEEE PI 394 interconnectivity speci- 
fication. 

3. The system of claim 1 wherein said event communi- 20 
cation and said first communications protocol are imple- 
mented according to an AV/C digital interface command set 
specification. 

. 4. The system of claim 1 wherein said first device is 
implemented as one of a base and a legacy device that are 25 
compatible with said first communications protocol. 

5. The system of claim 1 wherein said translated com- 
munication and said second communications protocol are 
compatible with network software implemented according 

to a home audio/visual interoperability specification. 30 

6. The system of claim 1 wherein said second device is 
implemented as one of a full device and an intermediate 
device that are compatible with said second communications 
protocol. 

7. The system of claim 1 wherein said self-DCM is 35 
implemented as part of network software on said second 
device, said network software being compatible with said 
second communications protocol. 

8. The system of claim 1 wherein said first device 
transmits said event communication to said second device, 40 
said event communication including information relating to 

an occurrence on said first device. 

9. The system of claim 8 wherein said event communi- 
cation is received and handled by a device driver corre- 
sponding to said second device. 45 

10. The system of claim 9 wherein said device driver 
handles said event communication in accordance with a 
control and status registers (CSR) architecture. 

11. The system of claim 9 wherein said self-DCM 
accesses said event communication from said device driver, 50 
and responsively processes and converts said event commu- 
nication into said translated communication. 

12. The system of claim 11 wherein a driver interface in 
said self-DCM communicates with said device driver to 
access said event communication. 55 

13. The system of claim 12 wherein a command processor 
in said self-DCM accesses said event communication from 
said driver interface, and responsively utilizes a handler to 
determine how to process and respond to said event com- 
munication. 60 

14. The system of claim 13 wherein a translator accesses 
said event communication from said command processor, 
and responsively converts said event communication into 
said translated communication. 

15. The system of claim 14 wherein a network software 65 
interface provides said translated communication to network 
software on said second device. 
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16. The system of claim 1 wherein said self-DCM posts 
said translated communication to an event manager in a 
local set of network software on said second device. 

17. The system of claim 16 wherein said event manager 
propagates a notification regarding said translated commu- 
nication to subscribed remote sets of network software 
across said electronic network. 

18. The system of claim 1 further comprising a third 
device coupled to said electronic network, said third device 
using a resource manager in network software to create a 
reservation for said second device to perform a scheduled 
action. 

19. The system of claim 18 wherein said event commu- 
nication from said first device creates a conflict with said 
reservation made by said third device. 

20. The system of claim 19 wherein said self-DCM 
provides said translated communication to said resource 
manager which responsively arbitrates and resolves said 
conflict. 

21. A method for efficiently implementing an electronic 
network, comprising the steps of: 

transmitting an event communication from a first device 
on said electronic network according to a first commu- 
nications protocol; and 

utilizing a self-DCM to convert said event communication 
into a translated communication that utilizes a second 
communications protocol which is compatible with a 
second device on said electronic network. 

22. The method of claim 21 wherein said event commu- 
nication and said first communications protocol are imple- 
mented according to an IEEE P1394 interconnectivity speci- 
fication. 

23. The method of claim 21 wherein said event commu- 
nication and said first communications protocol are imple- 
mented according to an AV/C digital interface command set 
specification. 

24. The method of claim 21 wherein said first device is 
implemented as one of a base and a legacy device that are 
compatible with said first communications protocol. 

25. The method of claim 21 wherein said translated 
communication and said second communications protocol 
are compatible with network software implemented accord- 
ing to a home audio/visual interoperability specification. 

26. The method of claim 21 wherein said second device 
is implemented as one of a full device and an intermediate 
device that are compatible with said second communications 
protocol. 

27. The method of claim 21 wherein said self-DCM is 
implemented as part of network software on said second 
device, said network software being compatible with said 
second communications protocol. 

28. The method of claim 21 wherein said first device 
transmits said event communication to said second device, 
said event communication including information relating to 
an occurrence on said first device. 

29. The method of claim 28 wherein said event commu- 
nication is received and handled by a device driver corre- 
sponding to said second device. 

30. The method of claim 29 wherein said device driver 
handles said event communication in accordance with a 
control and status registers (CSR) architecture. 

31. The method of claim 29 wherein said self-DCM 
accesses said event communication from said device driver, 
and responsively processes and converts said event commu- 
nication into said translated communication. 

32. The method of claim 31 wherein a driver interface in 
said self-DCM communicates with said device driver to 
access said event communication. 
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33. The method of claim 32 wherein a command proces- 
sor in said self-DCM accesses said event communication 
from said driver interface, and responsively utilizes a han- 
dler to determine how to process and respond to said event 
communication. S 

34. The method of claim 33 wherein a translator accesses 
said event communication from said command processor, 
and responsively converts said event communication into 
said translated communication. 

35. The method of claim 34 wherein a network software 10 
interface provides said translated communication to network 
software on said second device. 

36. The method of claim 21 wherein said self-DCM posts 
said translated communication to an event manager in a 
local set of network software on said second device. is 

37. The method of claim 36 wherein said event manager 
propagates a notification regarding said translated commu- 
nication to subscribed remote sets of network software 
across said electronic network. 

38. The method of claim 21 further comprising a third 20 
device coupled to said electronic network, said third device 
using a resource^ manager in network software to create a 
reservation for said second device to perform a scheduled 
action. 

39. The method of claim 38 wherein said event commu- 25 
nication from said first device creates a conflict with said 
reservation made by said third device. 



40. The method of claim 21 wherein said first device is 
implemented as one of a base, a legacy device, an interme- 
diate device, and a full device that are compatible with said 
first communications protocol. 

41. A system for efficiently implementing an electronic 
network, comprising: 

means for transmitting an event communication over said 
electronic network according to a first communications 
protocol; and 

means for converting said event communication into a 
translated communication that utilizes a second com- 
munications protocol which is compatible with a target 
device on said electronic network. 

42. A computer-readable medium comprising program 
instructions for efficiently implementing an electronic net- 
work by performing the steps of: 

transmitting an event communication from a first device 
on said electronic network according to a first commu- 
nications protocol; and 

utilizing a self-DCM to convert said event communication 
into a translated communication that utilizes a second 
communications protocol which is compatible with a 
second device on said electronic network. 
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